ci: pin Go toolchain to 1.26.4 and unify version source#770
Open
dlevy-msft-sql wants to merge 1 commit into
Open
ci: pin Go toolchain to 1.26.4 and unify version source#770dlevy-msft-sql wants to merge 1 commit into
dlevy-msft-sql wants to merge 1 commit into
Conversation
Fixes govulncheck failures for GO-2026-5037 (crypto/x509) and GO-2026-5039 (net/textproto), both fixed in Go 1.26.4. Changes: - go.mod: add 'toolchain go1.26.4' so go/setup-go know the minimum acceptable patch. - security.yml, pr-validation.yml, golangci-lint.yml: read version from go.mod (single source of truth) and set 'check-latest: true' so the runner fetches the newest matching patch from the signed actions/go-versions manifest instead of serving a stale cache entry (1.26.3). - security.yml: pin govulncheck to @v1.1.4 instead of @latest for supply-chain hygiene. The vuln DB itself is fetched at runtime, so this only pins the analyzer binary.
There was a problem hiding this comment.
Pull request overview
Updates the repository’s canonical Go patch level to 1.26.4 (to pick up stdlib security fixes needed for govulncheck) and aligns GitHub Actions workflows to consistently use go.mod as the single version source.
Changes:
- Add
toolchain go1.26.4togo.modto declare the minimum acceptable Go patch. - Update CI workflows to use
go-version-file: go.modandcheck-latest: trueto avoid stale runner cache patch versions. - Pin
govulncheckinstallation to a specific version instead of@latest.
Reviewed changes
Copilot reviewed 4 out of 4 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
| go.mod | Adds toolchain go1.26.4 so CI and developers use the patched Go toolchain. |
| .github/workflows/security.yml | Uses check-latest: true and pins govulncheck to v1.1.4 for more deterministic security scanning. |
| .github/workflows/pr-validation.yml | Switches to go-version-file: go.mod + check-latest: true to avoid workflow drift. |
| .github/workflows/golangci-lint.yml | Reorders steps to checkout before setup-go and unifies Go version sourcing via go.mod. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
govulncheckis failing on every PR (e.g. #769 run) with exit code 3:net/textprotoarbitrary input in errors (reached viacontainer.Controller.ContainerFiles→io.ReadAll)crypto/x509inefficient hostname parsing (reached viasqlCmdFormatterType.AddError→x509.HostnameError.Error)Both are stdlib bugs fixed in Go 1.26.4. The runner is using 1.26.3.
Root Cause
Two cooperating gaps:
go.moddeclaredgo 1.26with notoolchaindirective, so setup-go resolved "1.26" against its cached release manifest and happily returned 1.26.3 (already in cache) — even though 1.26.4 is published inactions/go-versions.go-version: '1.26.0'literally, so they drift fromgo.modand need manual edits for every Go bump.go/toolchaindirectives (dependabot-core#8454) and stdlib CVEs aren't inrequire(), so dependabot can't fix this for us.Solution
go.modtoolchain go1.26.4.github/workflows/security.ymlcheck-latest: trueto setup-goactions/go-versionsmanifest for the newest matching patch instead of serving a stale cache entry..github/workflows/security.ymlgovulncheck@latest→govulncheck@v1.1.4@latestsupply-chain edge. The vuln DB itself is fetched at runtime, so DB freshness is unchanged..github/workflows/pr-validation.ymlgo-version: '1.26.0'→go-version-file: go.mod+check-latest: truego.modis the only place the version lives..github/workflows/golangci-lint.ymlAfter this lands, bumping the Go patch is a one-line edit to the
toolchainline ingo.mod. All three workflows pick it up automatically on the next run.Testing
go build ./...locally withgo1.26.4(auto-downloaded by thetoolchaindirective) — succeeds.govulncheckwill be exercised by this PR's own security.yml run.Why not split the commits
go.mod and the workflows are one change with one motivating cause (govulncheck failure). Splitting would land the workflow changes first and still leave govulncheck red until the go.mod change merged separately.
Related
toolchainline bumps become frequent, add a scheduled workflow that opens a PR viapeter-evans/create-pull-request. Skipping for now — manual edits are fine given Go's patch cadence.